The current behavior of the lookup of external files is wildly inconsistent for each type and depends on if you are using the GUI or CLI. This can be mostly observed in test/cli/lookup_test.py (CLI) and https://trac.cppcheck.net/ticket/12752 (GUI).

This is a PR to determine the intended(!) order of the lookup of external files with goal of having a defined and shared implementation. The current change of the manual contains what I consider the most sensible order. Obviously open to any discussion/feedback on this.

I also considered making some of these lookups configurable to avoid some potentially unwanted behavior:
https://trac.cppcheck.net/ticket/12810
https://trac.cppcheck.net/ticket/13505

There's also other related tickets:
https://trac.cppcheck.net/ticket/10774
https://trac.cppcheck.net/ticket/13880

I did not include a list of the known issues as those are mostly evident by above references and should not affect the discussion and are simply the steps to ensure we arrive at the intended behavior.

CC @danmar @ludviggunne @andresailer @ledocc @nlebedenco @c72578

A case against supporting CWD in the lookup (from #7639 (comment)):

"It will look in the folder you run Cppcheck from. So on Linux, if you have files in your user folder (like we support in the GUI). And you open a new shell - which by default will start in the user folder. And you run Cppcheck immediately - it might pick up the files in the user folder (because it is the current CWD) before others. In that case supporting the CWD seems rather unexpected and arbitrary."

A case against supporting CWD in the lookup (from #7639 (comment)):

Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder.

"It will look in the folder you run Cppcheck from. So on Linux, if you have files in your user folder (like we support in the GUI). And you open a new shell - which by default will start in the user folder. And you run Cppcheck immediately - it might pick up the files in the user folder (because it is the current CWD) before others. In that case supporting the CWD seems rather unexpected and arbitrary."

I think that the typical use case is that users don't run cppcheck directly like that. they use a cppcheck project file or a shell script. the shell script probably uses relative paths because otherwise it's not possible to reuse it in the team..

Maybe I missed it? I do not see an alternative suggestion yet how configuration files would be found in the project folder.

It looks relative to the project file. Looking relative to the CWD is a different lookup. That should be evident in the expected output of test/cli/lookup_test.py

I think that the typical use case is that users don't run cppcheck directly like that. they use a cppcheck project file or a shell script. the shell script probably uses relative paths because otherwise it's not possible to reuse it in the team..

It will probably be installed in some common location. If files are distributed with it they would be placed relative to that so it will use the lookup relative to the executable location.

But you just gave the use case for CWD. If you have a custom script which invokes it you might place addition or overrides next to the script. The question though if CWD should override the project file - I think not, because the more specialized location should always override the more common ones.

But you just gave the use case for CWD. If you have a custom script which invokes it you might place addition or overrides next to the script. The question though if CWD should override the project file - I think not, because the more specialized location should always override the more common ones.

great. that is fine for me. so look in the project file folder first if that exist. and then look in CWD folder..

great. that is fine for me. so look in the project file folder first if that exist. and then look in CWD folder..

I am still a bit torn of supporting CWD. Because if you invoke the tool you might do so from a random path since the executable is in PATH. So that might pick up a stray file. Still there is your use-case.

clang-tidy is also picking up config files but that is starting from the source location and then walks up the tree. That is something we currently do not do. That would actually be similar to the project file behavior.

But clang-tidy also lets you specify config file locations. So we could add an option to inject a path in the lookup (which would be super easy when all the lookups have been converted to walking a list of paths).